<html lang="en">
<title>Release Notes for Apache Derby 10.10.2.0</title>
<body>
<h1>
<a name="Release Notes for Apache Derby 10.10.2.0"></a>Release Notes for Apache Derby 10.10.2.0</h1>
<div>
<p>These notes describe the difference between Apache Derby release 10.10.2.0 and the preceding release 10.10.1.1.</p>
</div>
<ul>
<li>
<a href="#Overview">Overview</a>
</li>
<li>
<a href="#New Features">New Features</a>
</li>
<li>
<a href="#Issues of special concern">Issues of special concern</a>
</li>
<li>
<a href="#Bug Fixes">Bug Fixes</a>
</li>
<li>
<a href="#Doc Fixes">Fixes in the Documentation</a>
</li>
<li>
<a href="#Build Environment">Build Environment</a>
</li>
<li>
<a href="#Verifying Releases">Verifying Releases</a>
</li>
</ul>
<h2>
<a name="Overview"></a>Overview</h2>
<div>


<p>
The most up to date information about Derby releases can be found on the
<a href="http://db.apache.org/derby/derby_downloads.html">Derby download page</a>.
</p>


<p>
Apache Derby is a pure Java relational database engine using standard SQL and
JDBC as its APIs. More information about Derby can be found on the
<a href="http://db.apache.org/derby/">Apache web site</a>.
Derby functionality includes:
</p>


<ul>

<li>Embedded engine with JDBC drivers</li>

<li>Network Server</li>

<li>Network client JDBC drivers</li>

<li>Command line tools: ij (SQL scripting), dblook (schema dump) and sysinfo (system info)</li>

</ul>


<p>
Java and JDBC versions supported:
</p>

<ul>
  
<li>Java SE 5 and higher with JDBC 3.0, 4.0, 4.1, and 4.2.</li>
  
<li>Java ME CDC/Foundation Profile 1.1 with JSR-169 JDBC Optional Package for CDC/Foundation Profile.</li>

</ul>

</div>
<h2>
<a name="New Features"></a>New Features</h2>
<div>


<p>
This is a bug fix release. There are no new features:
</p>


</div>
<h2>
<a name="Issues of special concern"></a>Issues of special concern</h2>
<div>
<p>Compared with the previous release (10.10.1.1), Derby release 10.10.2.0 introduces the following incompatibilities. These merit your special attention.</p>
<ul>
<li>
<a href="#Note for DERBY-6438"><span>Note for DERBY-6438: 
Additional permission needed to run Derby network server
</span></a>
</li>
<li>
<a href="#Note for DERBY-6383"><span>Note for DERBY-6383: 
After the fix, statement level update triggers defined on specific columns will only fire for the update of any of those specified columns.
Additionally, after the fix, statement level update triggers defined at the table level will fire correctly for columns added after the CREATE TRIGGER sql is issued.
</span></a>
</li>
<li>
<a href="#Note for DERBY-6270"><span>Note for DERBY-6270: Frame injection vulnerability in old versions of the API documentation.</span></a>
</li>
<li>
<a href="#Note for DERBY-6224"><span>Note for DERBY-6224: New SQLPermission needed for JDBC driver deregistration on Java SE 8.</span></a>
</li>
<li>
<a href="#Note for DERBY-6209"><span>Note for DERBY-6209: 

When running a server started from the command line with a security
manager and a customized policy file, new permissions may be have to
be added to it.

</span></a>
</li>
<li>
<a href="#Note for DERBY-6187"><span>Note for DERBY-6187: 
Datatype Change in JDBC Metadata
</span></a>
</li>
<li>
<a href="#Note for DERBY-5866"><span>Note for DERBY-5866: The meaning of SYS.SYSTRIGGERS.CREATIONTIMESTAMP has changed.</span></a>
</li>
</ul>
<hr>
<h3>
<a name="Note for DERBY-6438"></a>Note for DERBY-6438</h3>
<div>

<!-- 
  SUMMARIZE THE ISSUE. This is a one line, one sentence summary of the
  issue. It serves as the title for the issue in the Issues section of
  the full Release Notes.

  For instance:

  Applications may no longer open two InputStreams on the same ResultSet column.
-->


<h4>Summary of Change</h4>

<p>
Additional permission needed to run Derby network server
</p>


<!-- 
  DESCRIBE WHAT IT IS THAT THE USER ACTUALLY SEES WHEN THE PROBLEM OCCURS.

  For instance:

  In the previous release, applications were able to open two
  InputStreams on the same column. Depending on how these streams
  interacted, the value siphoned out of the column was erratic. Now
  Derby raises a SQLException when the application attempts to create
  the second InputStream.
-->


<h4>Symptoms Seen by Applications Affected by Change</h4>

<p>
An additional java.net.SocketPermission, "listen" was added to the default network server policy file, and the policy file template. The documentation was updated to describe this permission.

</p>


<!-- 
  OPTIONAL: DESCRIBE INCOMPATIBILITIES WITH PREVIOUS RELEASE, IF ANY.

  For instance:

  Applications which open two InputStreams on the ResultSet column now
  fail.
-->


<h4>Incompatibilities with Previous Release</h4>

<p>
No incompatibilities arise from upgrading a Derby release to one with the additional permissions in the policy file. <BR> 
However, unless you have this permission, when upgrading to a JVM release that has JDK 7u51 incorporated, your network server may not start if
<UL>

<LI> you use network server on a port not within the ephemeral ports specified by the OS.</LI>

<LI>
and
<UL>

<LI> you rely on the default derby policy file, or </LI>

<LI> you have a customized policy file without this permission</LI>

</UL>

</LI>

</UL>

</p>


<!-- 
  DESCRIBE WHY THE CHANGE WAS MADE.

  For instance:

  The previous behavior violated the JDBC standard. The new behavior
  is correct.
-->


<h4>Rationale for Change</h4>

<p>
An additional permission may be needed in order to bring up the Derby network server after upgrading to JVMs incorporating JDK 7u51. 
In particular, the startup scripts may fail to boot the network server.
</p>

<p>
This is a result of the "Better applet networking" changes made for JVM issue 8011787 (not public): the default socket permissions assigned to all code including untrusted code have been changed. <BR>
Previously, all code was able to bind any socket type to any port number greater than or equal to 1024. It is still possible to bind sockets to the ephemeral port range on each system. The exact range of ephemeral ports varies from one operating system to another, but it is typically in the high range (such as from 49152 to 65535). <BR>
The new restriction is that binding sockets outside of the ephemeral range now requires an explicit permission in the system security policy.
</p>

<p>
After upgrading to a JVM with these changes, while attempting to boot, the network server may fail and raise the following error:
<UL>
access denied ("java.net.SocketPermission" "localhost:1527" "listen,resolve")
java.security.AccessControlException: access denied 
("java.net.SocketPermission" "localhost:1527" "listen,resolve")
</UL>

To workaround this problem, you must bring up the network server with a security policy which includes the now required missing permission. Instead of booting the network server as:

<UL>
java org.apache.derby.drda.NetworkServerControl start
</UL>

boot the network server as follows:

<UL>
java -Djava.security.manager -Djava.security.policy=${yourPolicyFile}
org.apache.derby.drda.NetworkServerControl start
</UL>

where ${yourPolicyFile} is a file containing a customized version of the policy file described in the Derby Admin Guide section titled Basic Network Server security policy. You must customize that generic policy file to fit your application. In addition, you must add the following permission to the permissions block granted to the ${derby.install.url}derbynet.jar codebase:

<UL>
permission java.net.SocketPermission "localhost:${port}", "listen";
</UL>

where ${port} should be replaced by the port number where the network server listens for incoming connection requests. By default, that is port 1527.
</p>

<p>
For more information on Derby security policies, see the Derby Admin Guide sections titled Network Server security and Running the Network Server under the security manager.
</p>

<p>
If you are using replication, a similar permission must be granted to the security policy for the slave server. Add the following permission to the ${derby.install.url}derby.jar codebase:

<UL>
permission java.net.SocketPermission "localhost:${slavePort}", "listen";
</UL>

where ${slavePort} should be replaced by the port number where the slave server listens for incoming connection requests (typically 4851). For more information on the security policy for the slave server, see the Derby Admin Guide section titled Replication and security.

</p>

<p>
With this fix, the default policy file has received these required permissions, and the scripts in the bin directory work again. However, it may still be necessary to adjust any customized policy files.
</p>


<!-- 
  OPTIONAL: DESCRIBE HOW TO REVERT TO THE PREVIOUS BEHAVIOR OR
  OTHERWISE AVOID THE INCOMPATIBILITIES INTRODUCED BY THIS CHANGE.

  For instance:

  Users must recode applications which open multiple streams on the same column.
-->


<h4>Application Changes Required</h4>

<p>
Applications need not make any change to take advantage of the new permission granted in the default policy file.
However, the default policy file may, or may not be sufficient for specific applications and it is better to use your own policy file.
If you have your own policy file, you may need to adjust it to add the "listen" permission as appropriate.
</p>



</div>
<hr>
<h3>
<a name="Note for DERBY-6383"></a>Note for DERBY-6383</h3>
<div>



<h4>Summary of Change</h4>

<p>
After the fix, statement level update triggers defined on specific columns will only fire for the update of any of those specified columns.
Additionally, after the fix, statement level update triggers defined at the table level will fire correctly for columns added after the CREATE TRIGGER sql is issued.
</p>


<!-- 
  DESCRIBE WHAT IT IS THAT THE USER ACTUALLY SEES WHEN THE PROBLEM OCCURS.

  For instance:

  In the previous release, applications were able to open two
  InputStreams on the same column. Depending on how these streams
  interacted, the value siphoned out of the column was erratic. Now
  Derby raises a SQLException when the application attempts to create
  the second InputStream.
-->


<h4>Symptoms Seen by Applications Affected by Change</h4>

<p>
Statement level update triggers defined for specific columns fired on update of columns which were not included in the CREATE TRIGGER sql. Also, statement level update triggers defined at table level did not fire for newly added columns.
</p>


<!-- 
  OPTIONAL: DESCRIBE INCOMPATIBILITIES WITH PREVIOUS RELEASE, IF ANY.

  For instance:

  Applications which open two InputStreams on the ResultSet column now
  fail.
-->


<h4>Incompatibilities with Previous Release</h4>

<p>
Derby releases 10.7.1.4, 10.8.1.2, 10.9.1.0, 10.10.1.1 suffer from DERBY-6383 and will see 
1)update statement triggers defined at column(s) level firing for columns not specified in the column list of the "CREATE TRIGGER... AFTER UPDATE... OF" clause
2)update statement triggers defined at table level not firing for columns added to the table after CREATE TRIGGER was issued.
</p>

<!-- 
  DESCRIBE WHY THE CHANGE WAS MADE.

  For instance:

  The previous behavior violated the JDBC standard. The new behavior
  is correct.
-->


<h4>Rationale for Change</h4>

<p>
The fix for the regression identified in DERBY-6383 will now make update statement level triggers adhere to SQL standards.
</p>


<!-- 
  OPTIONAL: DESCRIBE HOW TO REVERT TO THE PREVIOUS BEHAVIOR OR
  OTHERWISE AVOID THE INCOMPATIBILITIES INTRODUCED BY THIS CHANGE.

  For instance:

  Users must recode applications which open multiple streams on the same column.
-->


<h4>Application Changes Required</h4>

<p>
In order to fix the buggy triggers created in the above mentioned releases, users will need to manually drop and recreate the 
statement level update triggers in a release with DERBY-6383 fix. All statement level update triggers, whether they are defined
on specific columns or at the table level, should be dropped and recreated.
</p>



</div>
<hr>
<h3>
<a name="Note for DERBY-6270"></a>Note for DERBY-6270</h3>
<div>

<!-- 
  SUMMARIZE THE ISSUE. This is a one line summary of the issue.

  For instance:

  Applications may no longer open two InputStreams on the same ResultSet column.
-->


<h4>Summary of Change</h4>


<p>Frame injection vulnerability in old versions of the API documentation.</p>

<!-- 
  DESCRIBE WHAT IT IS THAT THE USER ACTUALLY SEES WHEN THE PROBLEM OCCURS.

  For instance:

  In the previous release, applications were able to open two
  InputStreams on the same column. Depending on how these streams
  interacted, the value siphoned out of the column was erratic. Now
  Derby raises a SQLException when the application attempts to create
  the second InputStream.
-->


<h4>Symptoms Seen by Applications Affected by Change</h4>


<p>
Many of the previous releases of Apache Derby were built with JDK
versions whose javadoc tool produced HTML files that had a frame
injection vulnerability (CVE-2013-1571). The API documentation bundled
with this version of Apache Derby has been built with a version of the
javadoc tool that does not suffer from the vulnerability.
</p>

<!-- 
  OPTIONAL: DESCRIBE INCOMPATIBILITIES WITH PREVIOUS RELEASE, IF ANY.

  For instance:

  Applications which open two InputStreams on the ResultSet column now
  fail.
-->

<!-- h4>Incompatibilities with Previous Release</h4 -->


<!-- 
  DESCRIBE WHY THE CHANGE WAS MADE.

  For instance:

  The previous behavior violated the JDBC standard. The new behavior
  is correct.
-->


<h4>Rationale for Change</h4>


<p>
The change removes a vulnerability.
</p>

<!-- 
  OPTIONAL: DESCRIBE HOW TO REVERT TO THE PREVIOUS BEHAVIOR OR
  OTHERWISE AVOID THE INCOMPATIBILITIES INTRODUCED BY THIS CHANGE.

  For instance:

  Users must recode applications which open multiple streams on the same column.
-->


<h4>Application Changes Required</h4>


<p>
API documentation for old versions of Apache Derby on public-facing
web servers should be fixed by
</p>


<ul>

<li>removing the old versions of the API documentation, or</li>

<li>replacing the old versions of the API documentation with the new,
  fixed version in this release, or</li>

<li>repairing the vulnerable versions of the API documentation using
  Oracle's <a href="http://www.oracle.com/technetwork/java/javase/downloads/java-doc-updater-tool-1955731.html">
    Java API Documentation Updater Tool</a>

</li>

</ul>


</div>
<hr>
<h3>
<a name="Note for DERBY-6224"></a>Note for DERBY-6224</h3>
<div>

<!-- 
  SUMMARIZE THE ISSUE. This is a one line summary of the issue.

  For instance:

  Applications may no longer open two InputStreams on the same ResultSet column.
-->


<h4>Summary of Change</h4>


<p>New SQLPermission needed for JDBC driver deregistration on Java SE 8.</p>

<!-- 
  DESCRIBE WHAT IT IS THAT THE USER ACTUALLY SEES WHEN THE PROBLEM OCCURS.

  For instance:

  In the previous release, applications were able to open two
  InputStreams on the same column. Depending on how these streams
  interacted, the value siphoned out of the column was erratic. Now
  Derby raises a SQLException when the application attempts to create
  the second InputStream.
-->


<h4>Symptoms Seen by Applications Affected by Change</h4>


<p>
The symptoms are only seen when running an application under a Java
security manager on Java SE 8 or later.
</p>


<p>
When running the Apache Derby embedded driver under a Java security
manager on Java SE 8, the embedded driver will not be deregistered
during system shutdown
unless <code>SQLPermission("deregisterDriver")</code> has been granted
to <tt>derby.jar</tt>.
</p>


<p>
If this situation has occurred, the following message will be printed
to the Derby error log (<tt>derby.log</tt>) along with a stack trace
that tells where the call was made:
</p>


<p>
<tt>
Could not deregister the JDBC driver during engine shutdown. Make sure
SQLPermission("deregisterDriver") is granted to derby.jar.
</tt>
</p>


<p>
Also, if an application attempts to deregister a JDBC driver by
calling <code>java.sql.DriverManager.deregisterDriver()</code>
directly, it may fail with an AccessControlException. This is not
limited to the Apache Derby embedded driver; it will happen for any
JDBC driver, including the Apache Derby network client driver.
</p>

<!-- 
  OPTIONAL: DESCRIBE INCOMPATIBILITIES WITH PREVIOUS RELEASE, IF ANY.

  For instance:

  Applications which open two InputStreams on the ResultSet column now
  fail.
-->


<h4>Incompatibilities with Previous Release</h4>


<p>
When running on Java SE 7 or earlier, shutting down an embedded Derby
engine would also deregister the embedded driver
from <code>java.sql.DriverManager</code>'s list of JDBC drivers.
</p>


<p>
When running on Java SE 8 or later, the embedded driver will still be
registered after shutdown if <tt>derby.jar</tt> is not allowed to
invoke <code>java.sql.DriverManager.deregisterDriver()</code>.
</p>


<!-- 
  DESCRIBE WHY THE CHANGE WAS MADE.

  For instance:

  The previous behavior violated the JDBC standard. The new behavior
  is correct.
-->


<h4>Rationale for Change</h4>

<p>
This is a change in the <code>java.sql.DriverManager</code> class in Java
SE 8. It is not a change in Apache Derby.
</p>

<!-- 
  OPTIONAL: DESCRIBE HOW TO REVERT TO THE PREVIOUS BEHAVIOR OR
  OTHERWISE AVOID THE INCOMPATIBILITIES INTRODUCED BY THIS CHANGE.

  For instance:

  Users must recode applications which open multiple streams on the same column.
-->


<h4>Application Changes Required</h4>

<p>
Applications that run under a Java security manager, and that depend
on the driver being deregistered as a side-effect of shutting down the
embedded engine, need to
grant <code>java.sql.SQLPermission("deregisterDriver")</code>
to <tt>derby.jar</tt>.
</p>


<p>
Applications that run under a Java security manager, and that
call <code>java.sql.DriverManager.deregisterDriver()</code> directly,
need to grant <code>java.sql.SQLPermission("deregisterDriver")</code>
to the application code base, and possibly also change the call
to <code>deregisterDriver()</code> to go
through <code>java.security.AccessController.doPrivileged()</code>.
</p>


</div>
<hr>
<h3>
<a name="Note for DERBY-6209"></a>Note for DERBY-6209</h3>
<div>

<!-- 
  SUMMARIZE THE ISSUE. This is a one line, one sentence summary of the
  issue. It serves as the title for the issue in the Issues section of
  the full Release Notes.

  For instance:

  Applications may no longer open two InputStreams on the same ResultSet column.
-->


<h4>Summary of Change</h4>

<p>

When running a server started from the command line with a security
manager and a customized policy file, new permissions may be have to
be added to it.

</p>


<!-- DESCRIBE WHAT IT IS THAT THE USER ACTUALLY SEES WHEN THE PROBLEM
  OCCURS.

  For instance:

  In the previous release, applications were able to open two
  InputStreams on the same column. Depending on how these streams
  interacted, the value siphoned out of the column was erratic. Now
  Derby raises a SQLException when the application attempts to create
  the second InputStream.
-->


<h4>Symptoms Seen by Applications Affected by Change</h4>

<p>

Running the server will fail with a AccessControlException indicating
a missing permission, whereas running the server in the same way
used to work before upgrading Derby.


</p>


<!-- 
  OPTIONAL: DESCRIBE INCOMPATIBILITIES WITH PREVIOUS RELEASE, IF ANY.

  For instance:

  Applications which open two InputStreams on the ResultSet column now
  fail.
-->


<h4>Incompatibilities with Previous Release</h4>

Server will not run for affected configurations.

<!-- 
  DESCRIBE WHY THE CHANGE WAS MADE.

  For instance:

  The previous behavior violated the JDBC standard. The new behavior
  is correct.
-->

<h4>Rationale for Change</h4>

It is good security practice to limit data base file visibility to the
operating system account that creates the database. In this release of
Derby this policy is in effect by default <em>when starting the
network server from the command line</em> unless this functionality
has been explicitly disabled, cf. description of the property
<code>derby.storage.useDefaultFilePermissions</code> in the Reference Manual.
Cf. also Derby issue DERBY-5363.
<p>

<b>Note:</b> for other configurations, this policy must be explicitly
enabled, e.g when starting the server via the Java API. Similarly,
embedded Derby doesn't use the new policy by default. If you enable
the new policy in such configurations and a security manager is used,
you will need to add the permission described below to the Java
security policy file.
</p>

<!-- 
  OPTIONAL: DESCRIBE HOW TO REVERT TO THE PREVIOUS BEHAVIOR OR
  OTHERWISE AVOID THE INCOMPATIBILITIES INTRODUCED BY THIS CHANGE.

  For instance:

  Users must recode applications which open multiple streams on the same column.
-->


<h4>Application Changes Required</h4>

The implementation of this security policy requires that the policy
file in use by the server has a few more permissions than before. When
running with the default security policy that is taken care
of. However, for user customized policy files, these permissions need
be added.

The permissions that need be added are:

<ul>
  
<li>codebase <code>derbynet.jar</code>:
    <pre>
        permission java.lang.RuntimePermission "accessUserInformation";
	permission java.lang.RuntimePermission "getFileStoreAttributes";
	permission java.util.PropertyPermission "derby.__serverStartedFromCmdLine", "read, write";
    </pre>
  
</li>
  
<li>codebase <code>derby.jar</code>
    
<pre>
        permission java.lang.RuntimePermission "accessUserInformation";
	permission java.lang.RuntimePermission "getFileStoreAttributes";
    </pre>
  
</li>

</ul>

See also the template security policy file provided with Derby
at <code>demo/templates/server.policy</code> and the
section <em>Customizing the Network Server's security policy</em> in
the <em>Derby Server and Administration Guide</em>.

</div>
<hr>
<h3>
<a name="Note for DERBY-6187"></a>Note for DERBY-6187</h3>
<div>


<h4>Summary of Change</h4>

<p>
Datatype Change in JDBC Metadata
</p>



<h4>Symptoms Seen by Applications Affected by Change</h4>

<p>
The datatype has changed for two of the columns in the ResultSet
returned by DatabaseMetadata.getIndexInfo(). Previously, the
CARDINALITY and PAGES columns were INTs. Now they are BIGINTs.
</p>



<h4>Rationale for Change</h4>

<p>
JDBC 4.2 changed the datatype of these columns.
</p>



<h4>Application Changes Required</h4>

<p>
Note that on Derby, the contents of these columns is always NULL. Applications
may need to be recoded if they expect the metadata for these columns
to report that they have INT type rather than BIGINT type.
</p>



</div>
<hr>
<h3>
<a name="Note for DERBY-5866"></a>Note for DERBY-5866</h3>
<div>

<!-- 
  SUMMARIZE THE ISSUE. This is a one line summary of the issue.

  For instance:

  Applications may no longer open two InputStreams on the same ResultSet column.
-->


<h4>Summary of Change</h4>


<p>The meaning of SYS.SYSTRIGGERS.CREATIONTIMESTAMP has changed.</p>

<!-- 
  DESCRIBE WHAT IT IS THAT THE USER ACTUALLY SEES WHEN THE PROBLEM OCCURS.

  For instance:

  In the previous release, applications were able to open two
  InputStreams on the same column. Depending on how these streams
  interacted, the value siphoned out of the column was erratic. Now
  Derby raises a SQLException when the application attempts to create
  the second InputStream.
-->


<h4>Symptoms Seen by Applications Affected by Change</h4>


<p>
In earlier versions of Apache Derby,
the <tt>SYS.SYSTRIGGERS.CREATIONTIMESTAMP</tt> column would tell what
time the system clock showed, represented in the local time zone of
the database, at the time the trigger was created.
</p>


<p>
In databases whose format is upgraded to 10.11 or later, this column
now represents the time the trigger was created in the UTC time zone.
Existing values are not changed in the upgrade, so the creation
timestamps for any triggers created before the upgrade will still be
represented in the local time zone.
</p>


<p>
Furthermore, logic has been added to make the values in that column
monotonically increasing, so in some special cases (especially if the
system clock has been adjusted back in time, or if the database has
been moved to a machine whose system clock is behind the clock on the
original machine) the column may contain a value that is not equal to
the time the trigger was created. The latter change also takes effect
if the database format has not been upgraded to 10.11 or later.
</p>


<!-- 
  OPTIONAL: DESCRIBE INCOMPATIBILITIES WITH PREVIOUS RELEASE, IF ANY.

  For instance:

  Applications which open two InputStreams on the ResultSet column now
  fail.
-->

<!-- h4>Incompatibilities with Previous Release</h4 -->


<!-- 
  DESCRIBE WHY THE CHANGE WAS MADE.

  For instance:

  The previous behavior violated the JDBC standard. The new behavior
  is correct.
-->


<h4>Rationale for Change</h4>


<p>
The purpose of the <tt>SYS.SYSTRIGGERS.CREATIONTIMESTAMP</tt> column
is to make it possible to fire triggers in the order in which they
were created. A timestamp in the local time zone is not ideal for this
purpose because there are ambiguities in time zones that observe
daylight saving time. Also, there could be ambiguities when moving a
database to a machine in another time zone. Storing the timestamp in
UTC avoids both of these problems.
</p>


<p>
Another problem that was seen, was that triggers that were created
quickly after each other, could sometimes end up with the exact same
creation timestamp. This meant that the execution order for those
triggers was non-deterministic. The timestamp of a new trigger is now
adjusted so that it is higher than the timestamp of any other existing
trigger on the same table. This makes sure the triggers are executed
in the order in which they were created.
</p>

<!-- 
  OPTIONAL: DESCRIBE HOW TO REVERT TO THE PREVIOUS BEHAVIOR OR
  OTHERWISE AVOID THE INCOMPATIBILITIES INTRODUCED BY THIS CHANGE.

  For instance:

  Users must recode applications which open multiple streams on the same column.
-->


<h4>Application Changes Required</h4>


<p>
Most applications should not be affected by this change in any way.
Any applications that read the values stored
in <tt>SYS.SYSTRIGGERS.CREATIONTIMESTAMP</tt> should take into account
that this column doesn't necessarily tell the exact time the trigger
was created, because it contains a value that may have been adjusted
in order to ensure the correct execution order.
</p>


</div>
</div>
<h2>
<a name="Bug Fixes"></a>Bug Fixes</h2>
<div>
<p>The following issues are addressed by Derby release 10.10.2.0. These issues are not addressed in the preceding 10.10.1.1 release.</p>
<table border="2">
<tr>
<th>
<div style="width:110px;">Issue Id</div>
</th><th>Description</th>
</tr>
<tr>
<td><a href="https://issues.apache.org/jira/browse/DERBY-6513">DERBY-6513</a></td><td>Warnings when building 10.10 branch with Java 8</td>
</tr>
<tr>
<td><a href="https://issues.apache.org/jira/browse/DERBY-6477">DERBY-6477</a></td><td>OutOfMemoryError selecting from SYS.SYSALIASES</td>
</tr>
<tr>
<td><a href="https://issues.apache.org/jira/browse/DERBY-6463">DERBY-6463</a></td><td>localcal demo seems to be obsolete and should be removed</td>
</tr>
<tr>
<td><a href="https://issues.apache.org/jira/browse/DERBY-6457">DERBY-6457</a></td><td>NetworkServerControl API breaks when username or password contains non-ascii characters</td>
</tr>
<tr>
<td><a href="https://issues.apache.org/jira/browse/DERBY-6456">DERBY-6456</a></td><td>Infinite loop in NetworkServerControlImpl when reply &gt;= 32k</td>
</tr>
<tr>
<td><a href="https://issues.apache.org/jira/browse/DERBY-6455">DERBY-6455</a></td><td>Infinite loop in NetworkServerControlImpl.ensureDataInBuffer</td>
</tr>
<tr>
<td><a href="https://issues.apache.org/jira/browse/DERBY-6443">DERBY-6443</a></td><td>ArrayIndexOutOfBoundsException when calling function from trigger</td>
</tr>
<tr>
<td><a href="https://issues.apache.org/jira/browse/DERBY-6438">DERBY-6438</a></td><td>Explicitly grant SocketPermission "listen" in default server policy</td>
</tr>
<tr>
<td><a href="https://issues.apache.org/jira/browse/DERBY-6426">DERBY-6426</a></td><td>Fix isLoginException</td>
</tr>
<tr>
<td><a href="https://issues.apache.org/jira/browse/DERBY-6411">DERBY-6411</a></td><td>Minimal select privilege should be checked in subqueries</td>
</tr>
<tr>
<td><a href="https://issues.apache.org/jira/browse/DERBY-6408">DERBY-6408</a></td><td>EXISTS returns NULL instead of FALSE</td>
</tr>
<tr>
<td><a href="https://issues.apache.org/jira/browse/DERBY-6396">DERBY-6396</a></td><td>NullPointerException in DirFile</td>
</tr>
<tr>
<td><a href="https://issues.apache.org/jira/browse/DERBY-6387">DERBY-6387</a></td><td>Incorrect ordering of triggers in dblook</td>
</tr>
<tr>
<td><a href="https://issues.apache.org/jira/browse/DERBY-6383">DERBY-6383</a></td><td>Update trigger defined on one column fires on update of other columns</td>
</tr>
<tr>
<td><a href="https://issues.apache.org/jira/browse/DERBY-6374">DERBY-6374</a></td><td>Bulk insert of data with nullable UNIQUE constraint fails to detect duplicates</td>
</tr>
<tr>
<td><a href="https://issues.apache.org/jira/browse/DERBY-6373">DERBY-6373</a></td><td>NPE in Statement.getWarnings()</td>
</tr>
<tr>
<td><a href="https://issues.apache.org/jira/browse/DERBY-6371">DERBY-6371</a></td><td>DROP COLUMN looks in wrong schema when checking trigger dependencies</td>
</tr>
<tr>
<td><a href="https://issues.apache.org/jira/browse/DERBY-6363">DERBY-6363</a></td><td>Incorrect evaluation of logical expressions in CASE</td>
</tr>
<tr>
<td><a href="https://issues.apache.org/jira/browse/DERBY-6361">DERBY-6361</a></td><td>Valid statements rejected if Derby has not implicitly created the current user's schema.</td>
</tr>
<tr>
<td><a href="https://issues.apache.org/jira/browse/DERBY-6357">DERBY-6357</a></td><td>CREATE TRIGGER doesn't detect all illegal references to SESSION schema</td>
</tr>
<tr>
<td><a href="https://issues.apache.org/jira/browse/DERBY-6351">DERBY-6351</a></td><td>Syntax error on equal transition table name and correlation name in statement trigger</td>
</tr>
<tr>
<td><a href="https://issues.apache.org/jira/browse/DERBY-6348">DERBY-6348</a></td><td>NPE or assert failure in recursive trigger</td>
</tr>
<tr>
<td><a href="https://issues.apache.org/jira/browse/DERBY-6346">DERBY-6346</a></td><td>NPE in left join whose inner table has a generated column</td>
</tr>
<tr>
<td><a href="https://issues.apache.org/jira/browse/DERBY-6338">DERBY-6338</a></td><td>Remove Profile attribute from jar file manifests</td>
</tr>
<tr>
<td><a href="https://issues.apache.org/jira/browse/DERBY-6324">DERBY-6324</a></td><td>DatabaseMetaData.getJDBCMinorVersion() should return 2 now that we've implemented JDBC 4.2</td>
</tr>
<tr>
<td><a href="https://issues.apache.org/jira/browse/DERBY-6323">DERBY-6323</a></td><td>Fix incorrect @throws and @exception tags in javadoc</td>
</tr>
<tr>
<td><a href="https://issues.apache.org/jira/browse/DERBY-6320">DERBY-6320</a></td><td>Log a page dump to derby.log if ERROR nospc: nospc.U  is returned to the user</td>
</tr>
<tr>
<td><a href="https://issues.apache.org/jira/browse/DERBY-6317">DERBY-6317</a></td><td>Optmizer can choose the wrong path when BTreeCostController.java returns an estimate cost and row count of 0.0</td>
</tr>
<tr>
<td><a href="https://issues.apache.org/jira/browse/DERBY-6314">DERBY-6314</a></td><td>Upgrade from 10.10 fails with ClassCastException</td>
</tr>
<tr>
<td><a href="https://issues.apache.org/jira/browse/DERBY-6297">DERBY-6297</a></td><td>Intermittent failures in XplainStatisticsTest.testSimpleXplainOnly</td>
</tr>
<tr>
<td><a href="https://issues.apache.org/jira/browse/DERBY-6283">DERBY-6283</a></td><td>indexStat daemon processing tables over and over even when there are no changes in the tables in soft upgraded database.</td>
</tr>
<tr>
<td><a href="https://issues.apache.org/jira/browse/DERBY-6273">DERBY-6273</a></td><td>NullPointerException when using more than one parameter in COALESCE</td>
</tr>
<tr>
<td><a href="https://issues.apache.org/jira/browse/DERBY-6270">DERBY-6270</a></td><td>Run Java API Documentation Updater Tool on the published javadocs</td>
</tr>
<tr>
<td><a href="https://issues.apache.org/jira/browse/DERBY-6268">DERBY-6268</a></td><td>Run-time statistics not collected if query contains always false predicate</td>
</tr>
<tr>
<td><a href="https://issues.apache.org/jira/browse/DERBY-6258">DERBY-6258</a></td><td>Restrict permissions on BACKUP.HISTORY</td>
</tr>
<tr>
<td><a href="https://issues.apache.org/jira/browse/DERBY-6224">DERBY-6224</a></td><td>Issues with latest JDK 8 EA build because of missing SQLPermission</td>
</tr>
<tr>
<td><a href="https://issues.apache.org/jira/browse/DERBY-6221">DERBY-6221</a></td><td>Can't select from SYS.SYSUSERS if you use a WHERE clause in the query</td>
</tr>
<tr>
<td><a href="https://issues.apache.org/jira/browse/DERBY-6216">DERBY-6216</a></td><td>XPLAIN feature does not work and gives ERROR XCL16: ResultSet not open</td>
</tr>
<tr>
<td><a href="https://issues.apache.org/jira/browse/DERBY-6212">DERBY-6212</a></td><td>NullPointerException when calling a procedure with sub-query as argument</td>
</tr>
<tr>
<td><a href="https://issues.apache.org/jira/browse/DERBY-6209">DERBY-6209</a></td><td>Add release note omitted with 10.9 for new required Security Manager permissions after DERBY-5363</td>
</tr>
<tr>
<td><a href="https://issues.apache.org/jira/browse/DERBY-6189">DERBY-6189</a></td><td>NPE involving temporary table and rollback</td>
</tr>
<tr>
<td><a href="https://issues.apache.org/jira/browse/DERBY-6187">DERBY-6187</a></td><td>Add a release note for metadata datatype changes introduced by JDBC 4.2</td>
</tr>
<tr>
<td><a href="https://issues.apache.org/jira/browse/DERBY-6185">DERBY-6185</a></td><td>Query against view  with "where name LIKE 'Col1' ESCAPE '\' " failed</td>
</tr>
<tr>
<td><a href="https://issues.apache.org/jira/browse/DERBY-6167">DERBY-6167</a></td><td>Interrupt restarts clock for login timeout</td>
</tr>
<tr>
<td><a href="https://issues.apache.org/jira/browse/DERBY-6157">DERBY-6157</a></td><td>text for message XSLA4 might encouraging people to delete part of the transaction log</td>
</tr>
<tr>
<td><a href="https://issues.apache.org/jira/browse/DERBY-6151">DERBY-6151</a></td><td>Derby does not report warnings raised by table functions</td>
</tr>
<tr>
<td><a href="https://issues.apache.org/jira/browse/DERBY-6148">DERBY-6148</a></td><td>Wrong sort elimination when using permuted join order</td>
</tr>
<tr>
<td><a href="https://issues.apache.org/jira/browse/DERBY-6137">DERBY-6137</a></td><td>update/delete statement on table with trigger fails randomly with ERROR XSTA2</td>
</tr>
<tr>
<td><a href="https://issues.apache.org/jira/browse/DERBY-6131">DERBY-6131</a></td><td>select from view with "upper" and "in" list throws a ClassCastException</td>
</tr>
<tr>
<td><a href="https://issues.apache.org/jira/browse/DERBY-6114">DERBY-6114</a></td><td>OOME in XAMemTest.testDerby4137_TransactionTimeoutSpecifiedNotExceeded</td>
</tr>
<tr>
<td><a href="https://issues.apache.org/jira/browse/DERBY-6092">DERBY-6092</a></td><td>testPositionAgressive(org.apache.derbyTesting.functionTests.tests.jdbcapi.BlobClob4BlobTest)j fails with : 'The handle is invalid.: java.io.IOException'.</td>
</tr>
<tr>
<td><a href="https://issues.apache.org/jira/browse/DERBY-6047">DERBY-6047</a></td><td>NPE in StaticCallMethod#coerceMethodParameter with a constant argument to INOUT parameter</td>
</tr>
<tr>
<td><a href="https://issues.apache.org/jira/browse/DERBY-6045">DERBY-6045</a></td><td>in list multi-probe by primary key not chosen on tables with &gt;256 rows</td>
</tr>
<tr>
<td><a href="https://issues.apache.org/jira/browse/DERBY-5979">DERBY-5979</a></td><td>ant release target creates a release.properties that has conflicting line endings so automatic checkin fails</td>
</tr>
<tr>
<td><a href="https://issues.apache.org/jira/browse/DERBY-5886">DERBY-5886</a></td><td>FILE_CANNOT_REMOVE_FILE exception prints garbage.</td>
</tr>
<tr>
<td><a href="https://issues.apache.org/jira/browse/DERBY-5866">DERBY-5866</a></td><td>testFiringConstraintOrder(org.apache.derbyTesting.functionTests.tests.lang.TriggerTest)junit.framework.AssertionFailedError: matching triggers need to be fired in order creation:1,NO CASCADE BEFORE,DELETE,ROW</td>
</tr>
<tr>
<td><a href="https://issues.apache.org/jira/browse/DERBY-5865">DERBY-5865</a></td><td>On IBM 1.7 TestDurabilityProperty fails with  FAIL -- derby.system.durability=test mode seems to be broken.</td>
</tr>
<tr>
<td><a href="https://issues.apache.org/jira/browse/DERBY-5823">DERBY-5823</a></td><td>Multi-row insert fails on table without generated keys with RETURN_GENERATED_KEYS</td>
</tr>
<tr>
<td><a href="https://issues.apache.org/jira/browse/DERBY-5610">DERBY-5610</a></td><td>ServerPropertiesTest prints .java.net.SocketException: Connection reset to console but test passes</td>
</tr>
<tr>
<td><a href="https://issues.apache.org/jira/browse/DERBY-5560">DERBY-5560</a></td><td>Java deadlock between LogicalConnection40 and ClientXAConnection40 (patch attached)</td>
</tr>
<tr>
<td><a href="https://issues.apache.org/jira/browse/DERBY-5553">DERBY-5553</a></td><td>System property for client tracing -Dderby.client.traceDirectory does not work with XADataSource</td>
</tr>
<tr>
<td><a href="https://issues.apache.org/jira/browse/DERBY-5416">DERBY-5416</a></td><td>SYSCS_COMPRESS_TABLE causes an OutOfMemoryError when the heap is full at call time and then gets mostly garbage collected later on</td>
</tr>
<tr>
<td><a href="https://issues.apache.org/jira/browse/DERBY-4923">DERBY-4923</a></td><td>update of a long row can fail with ERROR nospc: nospc.U exception.</td>
</tr>
<tr>
<td><a href="https://issues.apache.org/jira/browse/DERBY-4753">DERBY-4753</a></td><td>"ERROR 42X01: Syntax error: FALSE." during call to java.sql.DatabaseMetaData.getIndexInfo</td>
</tr>
<tr>
<td><a href="https://issues.apache.org/jira/browse/DERBY-4729">DERBY-4729</a></td><td>add more information to the XACT_PROTOCOL_VIOLATION returned from store.</td>
</tr>
<tr>
<td><a href="https://issues.apache.org/jira/browse/DERBY-4160">DERBY-4160</a></td><td>getMetaData().getIndexInfo crashes with "ERROR X0Y68: Column 'PARAM1' already exists."</td>
</tr>
<tr>
<td><a href="https://issues.apache.org/jira/browse/DERBY-3940">DERBY-3940</a></td><td>Dropping a column does not drop triggers which mention that column</td>
</tr>
<tr>
<td><a href="https://issues.apache.org/jira/browse/DERBY-2130">DERBY-2130</a></td><td>Optimizer performance slowdown from 10.1 to 10.2</td>
</tr>
<tr>
<td><a href="https://issues.apache.org/jira/browse/DERBY-896">DERBY-896</a></td><td>Cast date to timestamp results in "ERROR 42846: Cannot convert types 'DATE' to 'TIMESTAMP'."</td>
</tr>
</table>
</div>

<h2>
<a name="Doc Fixes"></a>Fixes in the Documentation</h2>
<div>
<p>The following issues are addressed by Derby release 10.10.1.4. These issues are not addressed in the preceding 10.10.1.1 release.</p>
<table border="2">
<tr>
<th>
<div style="width:110px;">Issue Id</div>
</th><th>Description</th>
</tr>
<tr>
<td><a href="https://issues.apache.org/jira/browse/DERBY-6473">DERBY-6473</a></td><td>Manuals are inconsistent in subsubprotocol information</td>
</tr>
<tr>
<td><a href="https://issues.apache.org/jira/browse/DERBY-6448">DERBY-6448</a></td><td>Document new SocketPermission in Network Server policy file</td>
</tr>
<tr>
<td><a href="https://issues.apache.org/jira/browse/DERBY-6415">DERBY-6415</a></td><td>SYSCS_DIAG.SPACE_TABLE sample query to show all tables and indexes should include schema</td>
</tr>
<tr>
<td><a href="https://issues.apache.org/jira/browse/DERBY-6403">DERBY-6403</a></td><td>Doc for export/import in ref man should mention automatic commit after operation.</td>
</tr>
<tr>
<td><a href="https://issues.apache.org/jira/browse/DERBY-6399">DERBY-6399</a></td><td>clarify backup section in Derby Server and Administration Guide regarding connecting to the backed up db</td>
</tr>
<tr>
<td><a href="https://issues.apache.org/jira/browse/DERBY-6394">DERBY-6394</a></td><td>Fix problems with searchCondition and Boolean expression documentation in Reference Manual</td>
</tr>
<tr>
<td><a href="https://issues.apache.org/jira/browse/DERBY-6389">DERBY-6389</a></td><td>Update adminguide's list of differences between client and embedded</td>
</tr>
<tr>
<td><a href="https://issues.apache.org/jira/browse/DERBY-6388">DERBY-6388</a></td><td>Example WHERE CURRENT OF clause in Reference Guide is nonsense</td>
</tr>
<tr>
<td><a href="https://issues.apache.org/jira/browse/DERBY-6379">DERBY-6379</a></td><td>Manuals are inconsistent in their use of the &lt;shortdesc&gt; element</td>
</tr>
<tr>
<td><a href="https://issues.apache.org/jira/browse/DERBY-6376">DERBY-6376</a></td><td>Revise DatabaseMetaData section of Reference Manual</td>
</tr>
<tr>
<td><a href="https://issues.apache.org/jira/browse/DERBY-6375">DERBY-6375</a></td><td>Suggest use of indexes in devguide's deadlock avoidance topic</td>
</tr>
<tr>
<td><a href="https://issues.apache.org/jira/browse/DERBY-6369">DERBY-6369</a></td><td>Make bullet lists into tables in two Reference Manual topics</td>
</tr>
<tr>
<td><a href="https://issues.apache.org/jira/browse/DERBY-6367">DERBY-6367</a></td><td>Reference Manual incorrectly states that you can't schema-qualify constraint names</td>
</tr>
<tr>
<td><a href="https://issues.apache.org/jira/browse/DERBY-6355">DERBY-6355</a></td><td>Data Integrity guidelines should include not deleting or otherwise tampering with files under the database directory</td>
</tr>
<tr>
<td><a href="https://issues.apache.org/jira/browse/DERBY-6353">DERBY-6353</a></td><td>Update syntax description in Getting Started, use in Reference Manual too</td>
</tr>
<tr>
<td><a href="https://issues.apache.org/jira/browse/DERBY-6316">DERBY-6316</a></td><td>Small typos in devguide examples</td>
</tr>
<tr>
<td><a href="https://issues.apache.org/jira/browse/DERBY-6298">DERBY-6298</a></td><td>Documentation implies column NOT NULL constraint cannot be named, but it can be.</td>
</tr>
<tr>
<td><a href="https://issues.apache.org/jira/browse/DERBY-6239">DERBY-6239</a></td><td>Document optional permission SQLPermission("deregisterDriver")</td>
</tr>
<tr>
<td><a href="https://issues.apache.org/jira/browse/DERBY-6165">DERBY-6165</a></td><td>The shutdown documentation should mention that a shutdown attempt could fail if login timeouts are enabled.</td>
</tr>
<tr>
<td><a href="https://issues.apache.org/jira/browse/DERBY-6160">DERBY-6160</a></td><td>Fixes needed to documentation topics on security policy permissions</td>
</tr>
<tr>
<td><a href="https://issues.apache.org/jira/browse/DERBY-6129">DERBY-6129</a></td><td>Reference Manual gives incorrect datatype for SYSCOLUMNS.COLUMNNAME</td>
</tr>
<tr>
<td><a href="https://issues.apache.org/jira/browse/DERBY-6127">DERBY-6127</a></td><td>Tell users to make sure that the state of a user-defined aggregate needs to be serializable</td>
</tr>
<tr>
<td><a href="https://issues.apache.org/jira/browse/DERBY-6123">DERBY-6123</a></td><td>Optional tools documentation in the reference guide should mention that optional tools require derbytools.jar be in the CLASSPATH</td>
</tr>
<tr>
<td><a href="https://issues.apache.org/jira/browse/DERBY-6121">DERBY-6121</a></td><td>Regularize how we refer to object names in the Reference Manual</td>
</tr>
<tr>
<td><a href="https://issues.apache.org/jira/browse/DERBY-6120">DERBY-6120</a></td><td>Clarify that $ is the separator character which should be used for the external names of static nested classes</td>
</tr>
<tr>
<td><a href="https://issues.apache.org/jira/browse/DERBY-6116">DERBY-6116</a></td><td>Confusing description of limitation on user-defined aggregate names.</td>
</tr>
<tr>
<td><a href="https://issues.apache.org/jira/browse/DERBY-6103">DERBY-6103</a></td><td>Improve documentation of ROW_NUMBER function</td>
</tr>
<tr>
<td><a href="https://issues.apache.org/jira/browse/DERBY-6090">DERBY-6090</a></td><td>Package javadoc publishedapi/jdbc4/index.html out of date</td>
</tr>
<tr>
<td><a href="https://issues.apache.org/jira/browse/DERBY-5244">DERBY-5244</a></td><td>DatabaseMetaData.getColumns(null, null, tableName, null) does not return the columns meta for a SYNONYM</td>
</tr>
<tr>
<td><a href="https://issues.apache.org/jira/browse/DERBY-4847">DERBY-4847</a></td><td>Errors should be displayed if using wrong CLASSPATH to make documentation target for release</td>
</tr>
<tr>
<td><a href="https://issues.apache.org/jira/browse/DERBY-4629">DERBY-4629</a></td><td>Explicitly document  how to get case-insensitive sorts and comparisons of string data</td>
</tr>
<tr>
<td><a href="https://issues.apache.org/jira/browse/DERBY-4628">DERBY-4628</a></td><td>The Derby docs would be clearer if we replaced our jargon term "territory" with the term "locale" which is used commonly across the Java ecosystem.</td>
</tr>
<tr>
<td><a href="https://issues.apache.org/jira/browse/DERBY-4627">DERBY-4627</a></td><td>Document how to install your own custom collation for use in sorting and comparing string data values.</td>
</tr>
<tr>
<td><a href="https://issues.apache.org/jira/browse/DERBY-4280">DERBY-4280</a></td><td>Property not documented - derby.language.statementCacheSize</td>
</tr>
</table>
</div>

<h2>
<a name="Build Environment"></a>Build Environment</h2>
<div>
<p>Derby release 10.10.2.0 was built using the following environment:</p>
<ul>
<li>
<b>Branch</b> - Source code came from the 10.10 branch.</li>
<li>
<b>Machine</b> - Cygwin on Microsoft Windows 7.</li>
<li>
<b>Ant</b> - Apache Ant version 1.7.0 compiled on June 27 2008.</li>
<li>
<b>Compiler</b> - All classes were compiled by using Oracle the 1.8.0 32-Bit VM (build 25.0-b70, mixed mode).</li>
<li>
<b>JSR 169</b> - Java ME support was built using libraries from IBMs weme 6.2.</li>
</ul>
</div>
<h2>
<a name="Verifying Releases"></a>Verifying Releases</h2>
<div>


<p>It is essential that you verify the integrity of the downloaded
files using the PGP and MD5 signatures.  MD5 verification ensures the
file was not corrupted during the download process.  PGP verification
ensures that the file came from a certain person.</p>


<p>The PGP signatures can be verified using
<a href="http://www.pgpi.org/">PGP</a> or
<a href="http://www.gnupg.org/">GPG</a>.
First download the Apache Derby
<a href="http://svn.apache.org/repos/asf/db/derby/code/trunk/KEYS">KEYS</a>
as well as the <code>asc</code> signature file for the particular
distribution. It is important that you get these files from the ultimate
trusted source - the main ASF distribution site, rather than from a mirror.
Then verify the signatures using ...</p>


<pre>
% pgpk -a KEYS
% pgpv db-derby-X.Y.tar.gz.asc

<em>or</em>

% pgp -ka KEYS
% pgp db-derby-X.Y.tar.gz.asc

<em>or</em>

% gpg --import KEYS
% gpg --verify db-derby-X.Y.tar.gz.asc

</pre>


<p>To verify the MD5 signature on the files, you need to use a program
called <code>md5</code> or <code>md5sum</code>, which is
included in many unix distributions.  It is also available as part of
<a href="http://www.gnu.org/software/textutils/textutils.html">GNU
Textutils</a>.  Windows users can get binary md5 programs from <a href="http://www.fourmilab.ch/md5/">here</a>, <a href="http://www.pc-tools.net/win32/freeware/console/">here</a>, or
<a href="http://www.slavasoft.com/fsum/">here</a>.</p>


<p>We strongly recommend that you verify your downloads with both PGP and MD5.</p>



</div>
</body>
</html>
